home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990725-20000114 / 000445_news@columbia.edu _Wed Jan 12 10:24:38 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA07891
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 12 Jan 2000 10:24:37 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA23520
  7.     for kermit.misc@watsun.cc.columbia.edu; Wed, 12 Jan 2000 10:21:25 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: Arabic support in Kermit
  11. Date: 12 Jan 2000 15:21:23 GMT
  12. Organization: Columbia University
  13. Message-ID: <85i65j$muu$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <85i4c3$les$1@newsmaster.cc.columbia.edu>,
  17. Jeffrey Altman <jaltman@watsun.cc.columbia.edu> wrote:
  18. : In article <85hoqo$ouc$1@techftp.technion.ac.il>,
  19. :  <JODY@lib.haifa.ac.il> wrote:
  20. : : 
  21. : : I am trying to find out about support for Arabic in Kermit, in
  22. : : particular the version for Windows 95/98.
  23. : 
  24. : There is currently no support for Arabic in Kermit 95.
  25. :
  26. Except, of course, to the extent that Kermit 95 supports Unicode.
  27.  
  28. : : Currently, we display Arabic records from our bibliographic catalog on
  29. : : terminals capable of displaying a special font. But we are gradually
  30. : : phasing out our terminals, replacing them with PCs, and there the font
  31. : : won't work.  There is a terminal-emulation program, Reflection, that
  32. : : supports Arabic well enough, but the cost for the number of stations
  33. : : we'd need to install it on is prohibitive. So, the idea came up of
  34. : : checking out Kermit.
  35. : : 
  36. : : The website at Columbia implies that Arabic is not yet supported (it's
  37. : : on the wish-list), but I wondered whether there have has been any work
  38. : : done, by the Kermit staff or outside collaborators.
  39. : 
  40. : In order to support Arabic two things must happen:
  41. : 
  42. :  . we must complete the GUI version (which has taken us much longer
  43. :    than we could ever have expected.)
  44. : 
  45. :  . the internal virtual display model must be modified to support
  46. :    arbitrary double width characters.
  47. : 
  48. :  . someone is going to have to pay for the development of the
  49. :    Arabic portion of the Unicode font to be used
  50. : 
  51. Arabic support can come in different levels.  Proper Arabic support that
  52. would be acceptable to people who read and write Arabic does indeed require
  53. all sorts of complex context-sensitive shaping and rendering (and therefore
  54. a GUI screen), and possibly also implementation of bidirectional writing
  55. algorithms by the terminal.  As Jeff says, this is no trivial undertaking,
  56. and one for which we, on our own, lack the needed expertise.  And as Jeff
  57. says, there is the matter of the font.  There is still, as far as we know,
  58. no monospaced Unicode font suitable for terminal emulation that includes the
  59. glyphs needed for Arabic -- let alone Armenian, Hebrew, Georgian, or for
  60. that matter full VT100 graphics.  (Let alone Chinese, Japanese, and Korean!)
  61.  
  62. At the opposite extreme is "character-cell Arabic", similar to how Hebrew,
  63. or for that matter, Greek, Russian, or English are handled by a terminal.
  64. In this case the host character set would be something like ISO 8859-6 and
  65. the local one would be something like PC Code Page 864 or 1008, and writing
  66. direction is handled by the host application.  This we could do in short
  67. order, but of course the font would still be an issue.  The only reason we
  68. haven't done this so far is that nobody has ever indicated they would be
  69. satisfied with it (and many have indicated they wouldn't).
  70.  
  71. Somewhere in the middle is a duospaced character-cell approach, in which
  72. each Arabic character occupies either one or two cells on the terminal
  73. screen, and there is some agreement between terminal and host about how
  74. how this is done.  Something like this will probably also be needed for
  75. Chinese, Japanese, and Korean.
  76.  
  77. As you can see, it's a complicated question -- or at least a complicated
  78. answer!
  79.  
  80. - Frank